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(54) Mutiple user authentication for online console-based gaming 



(57) A console-based multi-user authentication 
process allows multiple users of a game console to be 
authenticated together in a single request/reply ex- 
change with an authentication entity. The results of 
which is the possession of a single ticket that can be 
used to prove authenticity of multiple authentication 
principals to one or more online services. Also described 
is a handshake process that can be used to initially es- 
tablish an authentication account for each game con- 
sole. In which the account creation server can trust that 
a genuine game console Is making the request. 
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Description 

TECHNICAL FIELD 



[0001] This invention relates to console-based ganning systems, and more particularly, to methods for authenticating 
multiple identities in a single reply/request exchange between a game console and an authentication entity. 



BACKGROUND 



£00021 Traditionally, gaming systems with a dedicated console were standalone machines that accommodated a 
limited number of players (e.g., 4). PC-based gaming grew in popularity in part due to the ability to play games online 
with many remote players over a network (e.g., the Internet). Thus, one trend for dedicated gaming systems is to 
provide broadband capabilities to facilitate online gaming, Microsoft Corporation recently announced its Xbox^" video 
gaming system that is equipped with a hard disk drive to enhance gaming, and broadband connectivity to support 
IS online gaming. 

[0003] Creating an online gaming system for a dedicated console poses several unique and difficult problems. One 
problem Go.ncerns authentication of the participants. To establish an online gaming event, a local game being played 
on one game console goes'online and communicates with other game consoles, players, and/or online services. This 
Involves some level of trust among the participants, which the game attempts to establish by identifying itself, the game 
console, and the one or more players currently on the machine to other participants on the network in a secure manner. 
Additionally, the game console may also want to discover trusted services with which it can communicate over the 
network. 

[0004] The PC-based games do not experience such problems. For Instance, PC-based games do not typically 
experience multiple simultaneous users; rather only a single user is involved in the online game. On a PC, the users 
can easily enter their data via keyboard and the trusted services are easily configurable. Also, PC users tolerate networi< 
operations that take a little longer. If the PC game takes five extra seconds to start because it is making multiple round- 
trips to an authentication server, no one will complain. This is not the case in the gaming worid. 
[0005] Accordingly, the constraints on a dedicated game console make authentication a difficult problem for the 
following reasons: 



• Consoles do not have keyboards. Game controllers are not efficient data-entry devices, thus user-entered data 
should be kept to a minimum. 

• Gaming systems are plug-and-go; they plug into the wall and are ready for play. Configuration Is not expected or 
tolerated in the game console community. 

35 . Console games should be playablef with as little start up time as possible. Players expect to put a game disk Into 
the console, turn it on. and be playing the game a few seconds later. 

Consoles are a closed development environment in order to ensure high content quality. Thus, consoles need to 
know that they are communicating with trusted, quality controlled sen^ices. The need for trusted communications 
is further driven by the addition of a hard disk drive into the console in that any malicious damage rendered to the 
hard disk drive's data by an extemal source makes It difficult or Impossible to repair without reformatting. 



[0006] Cheating is not yet a major problem in the online console-based gaming community. In anticipation that it 
might one day pose a problem, there is a need for a solution that addresses cheating. Part of the solution is to make 
the console itself as secure as possible and tamper resistant, such that any tampering by a user will be discovered or 
^5 render the console inoperable. While security and tamper resistant solutions help, it does not prevent the case where 
a rogue player writes PC software to emulate a console machine on the network, enabling cheating without a game 
console. 

[0007] To prevent such impostor cheating, there is a need for an authentication protocol that verifies a player claiming 
to be on a console machine really is that player, as well as guarantees that the game console is indeed a trusted game 
so console and not an impostor or one that has been compromised. 

SUIViMARY 

[0008] A console-based multi-user authentication process allows multiple users of a game console to be authenti- 
S5 cated together in a single request/reply exchange with an authentication entity. 

[0009] In the described implementation, the game console is equipped with a hard disk drive, a portable media drive, 
and broadband connectivity to enable networi< access to a ticket issuing entity and one or more online services. When 
the game console desires to use the online service, it first obtains a ticket for that service from the ticket issuing entity. 
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The game console submits a request to the ticket issuing entity that contains a game console identity, the identities of 
the multiple users, and an identity of the desired online service. 

[0010] In response, the ticket issuing entity generates a ticket containing the game console identity and the multiple 
user identities together encrypted with the online service's key. The ticket issuing entity returns the ticket to the game 
console, which passes it onto the online service. The online service uses the ticket to verify the authenticity of the game 
console and the multiple users. In this manner, the single ticket obtained from the ticket issuing entity proves the 
particular game console as well as the multiple user identities playing at the game console. 

[0011] The game console identity is created when the game console first establishes a game account for online 
gaming. During manufacturing, the game console is constructed with pieces of infonmation that may be made available 
programmatically (e.g.. hard disk ID, CPU ID. serial number, random number, a value derived as a function of an ID 
or serial number, a quantity or some other mark written onto the hard drive, etc.). This infomnation is recorded in a 
database, which is subsequently made available to an authentication server. When the game console seeks a game 
account, it submits the pieces of infonmation to the authentication sen/er. Using the database, the server evaluates 
whether the pieces are legitimate and correspond to a game console that has not yet established an account. If the 
evaluation proves positive, a game account is created for that game console and the game console identity is assigned 
to the game console. 

BRIEF DESCRIPTION OF THE DRAWINGS 
[0012] 

Fig. 1 illustrates a gaming system with a game console and one or more controllers. 
Fig. 2 is a block diagram of the gaming system. 

Fig. 3 illustrates a network gaming system in which the Fig. 1 gaming system is connected via a network to other 
consoles, services, and a ticket Issuing entity. 

Fig. 4 illustrates a multi-user authentication process Involving three participants: a game console, a ticket issuing 
entity, and an online service. 

Fig. 5 is a flow diagram of the multi-user authentication process that facilitates authentication of multiple identi- 
ties — game console, game title, multiple users. 

Fig. 6 is a flow diagram of a process for establishing a game console identity that is used in the multi-user authen- 
tication process. 

DETAILED DESCRIPTION 

[0013] The following discussion Is directed to console-based online gaming systems and techniques for authenticat- 
ing multiple identities game console, game title, multiple users — in one authentication roundtrip. The discussion 

assumes that the reader is familiar with basic cryptography principles, such as encryption, decryption, authentication, 
hashing, and digital signatures. For a basic introduction to cryptography, the reader is directed to a text written by Bruce 
Schneier and entitled. "Applied Cryptography: Protocols. Algorithms, and Source Code in C." published by John Wiley 
& Sons, copyright 1 994 (second edition 1 996), which is hereby incorporated by reference. 

Gaming System 

[0014] Fig. 1 shows an exemplary gaming system 1 00. It includes a game console 1 02 and up to four controllers, 
as represented by controllers 104(1) and 104(2). The game console 102 is equipped with an internal hard disk drive 
and a portable media drive 1 06 that supports various fomns of portable storage media as represented by optical storage 
disc 108. Examples of suitable portable storage media include DVD. CD-ROM, game discs, game cartridges, and so 
forth. 

[0015] The game console 102 has four slots 110 on its front face to support up to four controllers, although the 
number and arrangement of slots may be modified. A power button 112 and an eject button 114 are also positioned 
on the front face of the game console 102. The power button 112 switches power to the game console and the eject 
button 114 alternately opens and closes a tray of the portable media drive 106 to allow insertion and extraction of the 
storage disc 108. 

[0016] The game console 102 connects to a television or other display (not shown) via A/V interfacing cables 120. 
A power cable 122 provides power to the game console. The game console 1 02 may further be configured with broad- 
band capabilities, as represented by the cable or modem connector 124 to facilitate access to a networtc, such as the 
internet. 

[0017] Each controller 104 is coupled to the game console 102 via a wire or wireless interface. In the illustrated 
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implementation, the controllers are USB (Universal Serial Bus) compatible and are connected to the console 102 via 
serial cables 1 30. The controller 1 02 may be equipped with any of a wide variety of user interaction mechanisms: As 
illustrated in Fig. 1 , each controller 104 is equipped with two thumbstlcks 132(1) and 132(2), a D-pad 134, buttons 136, 
and two triggers 138. These mechanisms are merely representative, and other known gaming mechanisms may be 

5 substituted for or added to those shown in Fig, 1 . 

[001 8] A memory unit (MU) 1 40 may be inserted Into the controller 1 04 to provide additional and portable storage. 
Portable memory units enable users to store game parameters and port them for play on other consoles. In the de- 
scribed Implementation, each controller Is configured to accommodate two memory units 140, although more or less 
than two units may be employed in other implementations. 

10 [0019] The gaming system 100 is capable of playing, for example, games, music, and videos. With the different 
. storage offerings, titles can be played from the hard disk drive or the portable medium 1 08 In drive 1 06, from an online 
source, or from a memory unit 140. A sample of what the gaming system 100 is capable of playing back include: 
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1 . Game titles played from CD and DVD discs, from the hard disk drive, or from an online source. 

2. Digital music played from a CD in the portable media drive 106. from a file on the hard disk drive (e.g., Windows 
Media Audio (WMA) format), or from online streaming sources. 

3. Digital audio/video played from a DVD disc in the portable media drive 1 06. from a file on the hard disk drive 
(e.g.. Active Streaming Format), or from online streaming sources. 



[0020] Fig. 2 shows functional components of the gaming system 1 00 in more detail. The game console 1 02 has a 
central processing unit (CPU) 200 and a memory controller 202 that facilitates processor access to various types of 
memory, Including a flash ROM (Read Only Memory) 204, a RAM (Random Access Memory) 206, a hard disk drive 
208. and the portable media drive 106. The CPU 200 is equipped with a level 1 cache 210 and a level 2 cache 212 to 
temporarily store data and hence reduce the number of memory access cycles, thereby improving processing speed 
25 and throughput. 

[0021 ] The CPU 200, memory controller 202, and various memory devices are interconnected via one or more buses, 
including serial and parallel buses, a memory bus, a peripheral bus. and a processor or local bus using any of a variety 
of bus architectures. By way of example, such architectures can include an Industry Standard Architecture (ISA) bus, 
a Micro Channel Architecture (MCA) bus, an Enhanced ISA (EISA) bus, a Video Electronics Standards Associatiori 
30 (VESA) local bus, and a Peripheral Component Interconnects (PCI) bus also known as a Mezzanine bus. 

[0022] As one suitable implementation, the CPU 200, memory controller 202. ROM 204, and RAM 206 are integrated 
onto a common module 214. In this implementation, ROM 204 is configured as a flash ROM that is connected to the 
memory controller 202 via a PCI (Peripheral Component Interconnect) bus and a ROM bus (neither of which are shown). 
RAM 206 is configured as multiple DDR SDRAM (Double Data Rate Synchronous Dynamic RAM) that are independ- 
35 ently controlled by the memory controller 202 via separate buses (not shown). The hard disk drive 208 and portable 
media drive 106 are connected to the memory controller via the PCI bus and an ATA (AT Attachment) bus 21 6. 
[0023] A 3D graphics processing unit 220 and a video encoder 222 form a video processing pipeline for high speed 
and high resolution graphics processing. Data is carried from the graphics processing unit 220 to the video encoder 
222 via a digital video bus (not shown). An audio processing unit 224 and an audio codec (coder/decoder) 226 form 
40 a corresponding audio processing pipeline with high fidelity and stereo processing. Audio data is carried between the 
audio processing unit224 and the audio codec 226 via a communication link (not shown). The video and audio process- 
ing pipelines output data to an A/V (audioA/ideo) port 228 for transmission to the television or other display. In the 
illustrated implementation, the video and audio processing components 220-228 are mounted on the module 214. 
[0024] Also implemented on the module 21 4 are a USB host controller 230 and a networi< interface 232. The USB 
host controller 230 is coupled to the CPU 200 and the memory controller 202 via a bus (e.g., PCI bus) and serves as 
host for the peripheral controllers 1 04(1 )-1 04(4). The network interface 232 provides access to a networi< (e.g. . Internet, 
home network, etc.) and may be any of a wide variety of various wire or wireless interface components including ari 
Ethernet card, a modem, a Bluetooth module, a cable modem, and the like. 

[0025] The game console 102 has two dual controller support subassemblies 240(1) and 240(2). with each sub- 
assembly supporting two game controllers 1 04(1 )-1 04(4). A front panel t/O subassembly 242 supports the functionality 
of the power button 1 1 2 and the eject button 1 1 4, as well as any LEDs (light emitting diodes) or other indfcators exposed 
on the outer surface of the game console. The subassemblies 240(1), 240(2). and 242 are coupled to the module 214 
via one or more cable assemblies 244. 

[0026] Eight memory units 140(1 )-1 40(8) are illustrated as being connectable to the four controllers 1 04(1 )-1 04(4), 
i.e., two memory units for each controller. Each memory unit 140 offers additional storage on which games, game 
parameters, and other data may be stored. When inserted into a controller, the memory unit 140 can be accessed by 
the memory controller 202. 

[0027] A system power supply module 250 provides power to the components of the gaming system 1 00. A fan 252 
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cools the circuitry within the game console 102. 

[0028] A console user interface (Ul) application 260 is stored on the hard disk drive 208. When the game console is 
powered on. various portions of the console application 260 are loaded into RAM 206 and/or caches 210. 212 and 
executed on the CPU 200. The console application 260 presents a graphical user interface that provides a consistent 
user experience when navigating to different media types available on the game console. 

[0029] The game console 1 02 implements a cryptography engine to perfonn common cryptographic functions, such 
as encryption, decryption, authentication, digital signing, hashing, and the like. The cryptography engine may be im- 
plemented as part of the CPU 200, or in software stored on the hard disk drive 208 that executes on the CPU, so that 
the CPU is configured to perform the cryptographic functions. 

[0030] The gaming system 100 may be operated as a standalone system by simply connecting the system to a 
television or other display. In this standalone mode, the gaming system 100 allows one or more players to play games, 
watch movies, or listen to music. However, with the integration of broadband connectivity made available through the 
network interface 232. the gaming system 1 00 may further be operated as a participant in a larger network gaming 
community. This network gaming environment Is described next. 

Network Gaming 

[0031 ] Fig. 3 shows an exemplary network gaming environment 300 that interconnects multiple gaming systems 1 00 
(1), .... 100(g) via a network 302. The network 302 represents any of a wide variety of data communications networks. 
It rnay include public portions (e.g.. the Internet) as well as private portions (e.g.. a residential Local Area Network 
(LAN)), as well as combinations of public and private portions. Networi< 302 may be implemented using any one or 
more of a wide variety of conventional communications media including both wired and wireless media. Any of a wide 
variety of communications protocols can be used to communicate data via network 302. including both public and 
proprietary protocols. Examples of such protocols include TCP/IP. IPX/SPX; NetBEUI, etc. 

[0032] In addition to gaming systems 1 00, one or more online services 304(1 ) 304(s) may be accessible via the 

network 302 to provide various services for the participants, such as hosting online games, serving downloadable 
music or video files, hosting gaming competitions, serving streaming audio/video files, and the like. The networi^ gaming 
environment 300 may further involve a key distribution center 306 that plays a role in authenticating individual players 
and/or gaming systems 1 00 to one another as well as online services 304, The distribution center 306 distributes keys 
and service tickets to valid participants that may then be used to form games amongst multiple players or to purchase 
services from the online services 304. 

[0033] The network gaming environment 300 introduces another memory source available to individual gaming sys- 
tems 100 online storage. In addition to the portable storage medium 108, the hard disk drive 208, and the memory 

unit(s) 140. the gaming system 100(1) can also access data files available at remote storage locations via the networi^ 
302, as exemplified by remote storage 308 at online service 304(s). 

Multi-User Authentication 

[0034] To participate in an online gaming situation, it is desirable for every participant to authenticate themselves to 
one another. Ideally, the entities that should be authenticated include the users, the game title, the game console, and 
any online service the might be involved. One approach to authenticating each entity is to employ the well-known 
Kerberos authentication protocol, which is described in the above referenced Schneier book. With the Kerberos au- 
thentication protocol, each user would perform an independent authentication cycle with the key distribution center 
because Kerberos is only used to authenticate a single user identity at a time. Unfortunately, this results in multiple 
authentication cycles for the various users, which is undesirable in the gaming context. 

[0035] To authenticate multiple users, the gaming system implements an authentication process that allows simul- 
taneous authentication of all entities— game console, game title, and multiple users— in one request/reply exchange 
with the key distribution center. Moreover, a single ticket can be used to prove the particular game console and the 
multiple user identities playing at the game console. This is very efficient and highly desirable in the gaming context. 
In the described implementation, the process is a KertDeros-like authentication protocol. 

[0036] Fig. 4 shows three primary participants in the multi-user authentication process: the gaming system 100(1), 
an online sen/ice 304. and the key distribution center 306. The participants are networked together via the networi< 
302 (not shown in Fig. 4) and are each capable of perfomning one or more routine cryptographic functions, such as 
encryption, decryption, one way hashing, random number generation, digital signing, and the like. Although more par- 
ticipants may be involved in the online gaming event, the Illustrated participants represent an exemplary set of partic- 
ipants that are involved in the multi-user authentication process. 

[0037] For discussion purposes, suppose there are four users of the gaming system 100(1), as represented by the 
four controllers 1 04(1 )-1 04(4). Each user is given an identity U^. Ug. U3. and U^ and is assigned a user key K^. Kg. K3, 
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and K4. The game console 102 is also assigned Its own identity X and a ganne console key Kx- (One exemplary 
approach to assigning the game console identity and key is described below in more detail with reference to Fig. 6.) 
Additionally, the game title, which Is shown here as a game disc 108, is assigned a separate identity G. In a similar 
manner, the online service 304 is assigned its own identity A and a key K;^. 

[9d38] The multi-user authentication process may be understood as a four-step process conducted in two roundtrip 
communication cycles. The first two steps occur during a single roundtrip request/reply exchange between the gaming 
system 1 00(1 ) and the key distribution center 306. which is illustrated as paths 402 and 404. The latter two steps occur 
during a single roundtrip request/reply exchange between the gaming system 100(1) and the online service 304, which 
is illustrated as paths 406 and 408. Note that the 406 request and 408 response are usually piggy backed on a regular 
online service request, and thus does not incur an extra round trip. Thus, the full authentication process may be carried 
out very quickly, with minimal information exchanges between the participants. 

[0039] During the first request/reply exchange, the gaming system 100(1) submits a request asking the key distri- 
bution center 306 to issue a single ticket on behalf of all identities — game console X, game title G, and all four users 
U^, U2, Uq, and U4 — for purposes of participating with the online service 304 (i.e., path 402 in Fig. 4). The key distri- 
bution center 306 generates and returns a ticket for use with the desired online sen/ice (i.e., path 404 in Fig. 4). In this.^ 
manner, the key distribution center 306 functions as a ticket issuing entity that issues tickets for services. 
[0040] During the second request/reply exchange, the gaming system 1 00(1 ) submits the ticket to the online service 
304 for authentication (I.e., path 406 in Fig. 4). The ticket is piggyback infomiatlon along with the first request for the 
online service, and does not need to be sent in a separate request or until the service is needed. If valid, the online 
service 304 sends back a reply that can be used by the gaming system 100(1) to authenticate the online service 304 
(i.e., path 408 In Fig. 4). If all entities are authenticated, the gaming system 100(1) can trust the retumed results from 
the online service and can continue to interact with the online service 304. 

[0041] The process illustrated in Fig. 4 is advantageous in that a single ticket obtained from the key distribution center 
306 is used to prove the game console and the multiple user identities playing at the game console. This is much more 
efficient than the traditional approach where multiple tickets are needed, one for each authenticated principal. 
[0042] Fig. 5 shows the multi-user authentication process 500 that is implemented by the three participants of Fig. 
4. The process can be implemented in software as computer-executable instructions stored on various storage media 
at the participants. When executed, the instructions direct the various participants to perform operations illustrated as 
blocks in Fig. 5. The tasks are illustrated beneath headings "Key Distribution Center", "Game Console", and "Online 
Service" to convey an exemplary location as to which entities are performing them. The multi-user authentication 
process 500 will be described with reference to both Figs. 4 and 5. 

[0043] At block 602 in Fig. 5, the game console 102 generates validated user identities based on the user identities 
Ui, Ug, U3, and U4 and user keys K^, Kg. K3, and K4. More specifically, the validated user identities include the user 
identities and values derived from the user keys. The validated user identities will be submitted with the request and 
used to demonstrate to the key distribution center 306 that the gaming system has knowledge of the user key and 
hence, implicitly authenticates the users. 

[0044] One way to generate the key derivative value is to compute a cryptographic hash of the user key using the 
key of the game console. For user with key K^, a hash is computed as follows: 

Hi =HMACk,(K,) 

[0045] The hash forms the key derivative value. Another way Is to encrypt the current time using the user key K^, 
as follows: 

Hi=Ek,(T) 

[0046] Once again, the resulting value forms the key derivative value. The validated user identity is the combi- 
nation of the user Identity and the corresponding key derivative value H^: 

Validated User Identity = (Ui. H,). 

[0047] At block 504 in Fig. 5, the game console 102 constructs a request containing the game console identity X. 
the game title identity G, the online service identity A of the service being requested, and multiple validated user 
identities (U^, H^), (U2. Hg), (U3, H3), and (U4. H4), The request has the following identity string: 
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Request = [X. G. A. (U,. H,). (Ug. Ha). (U3. H3). (U^. H^)] 

[0048] If the gaming system wanted authentication for more than online service, the identities of other services B, 
C. .... etc. are added to the request. Additionally, the request nriay include a version of the authentication protocol and 
a random nonce generated by the game console to resist replay attacks. The request may further Include a checksum 
value to be used to verify receipt of the entire identity string. The game console 102 submits the request over the 
network.302 to the key distribution center 306 (i.e.. path 402). 

[0049] At block 506 in Fig. 5. the key distribution center 306 evaluates the request as well as the identities contained 
in the request. The distribution center 306 generates a random session key to be used for each service being requested 
by the gaming system 100(1). In this example, the center 306 generates a random session.key Kxa to be used during 
the second communication cycle involving the game console 102 and the online service 304. If other sen^ices are 
requested, additional random session keys Kxb, Kxc etc. are produced. 

[0050] At block 508 in Fig. 5. the key distribution center 306 generates a ticket that will subsequently be presented 
to the requested online sen/ice. There is one ticket issued for each service requested, but each ticket is effective for 
multiple users. The ticket contains the identity string submitted in the request. It also includes a time T© that the ticket 
is generated, a time T^ identifying the time length before expiration of the ticket, and the randomly generated session 
key Kxa ^or the service requested. The ticket contents are encrypted via a symmetrte key cipher (e.g., DES) that utilizes 
the online service's key K^, as follows: 

TicketA = EkaFg. ^l* ^xa. X. A. .U2.U3.U4] 

[0051 ] Notice that the ticket does not carry the con-esponding key derivative values Hj. Once the authentication server 
reads the key derivative values and believes the game console knows the user keys, the authentication server places 
the identities of the users within the Issued tickets. Individual online services will subsequently believe in whatever the 
ticket tells it and hence do not need to see the key derivative values H,. 

[0052] If the gaming system sought tickets for more than one sen/ice, the key distribution center 306 issues multiple 
tickets, each ticket being encrypted with the public key of the desired online service, as follows: 

Tickets = EkbUg. Tl. Kxq. X. G. B. U,,U2.U3.U4] 
TicketC = EkcUq. T^. Kxc. X. G. C, Ui,U2.U3,U J 



TickeiN = EKwrTe. Tl. Kxn, X. G, N. U1.U2.U3.U4] 

[0053] At block 51 0 in Fig. 5, the key distribution center 306 returns each ticket over the networic 302 to the gaming 
system 100(1) (i.e., path 404). Since the game console 102 does not know the online service's key Ka, the game 
console 1 02 cannot open the ticket and alter the contents. The key distribution center also returns the session keys in 
an attached encrypted message. The session key message contains the ticket generation time Tq, the ticket expiration 
length Tl, and one or more session keys Kxa. ^xb- Kxc« etc., and all contents are encrypted using the game console's 
key Kx, as follows: 

Session Key Message = E,^|Tq. T^, Kxa. Kxb» Kxc. -l 

[0054] Since the session key message is encrypted with the game console's key K^. the game console 102 Is able 
to open the session key message and recover the session time parameters and session keys. 
[0055] . At block 512 in Fig. 5. the game console 102 passes the ticket, as is, onto the online service 304 (i.e., path 
406). The game console 102 also generates and sends the current time T (instead of its own ID) encrypted with the 
random session key Kxa- as follows: 



Time Message = EkxaITI 
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[0056] At block 514 in Fig. 5, the online service 304 evaluates the authenticity of the ticket. It decrypts the ticket 
using its key K;^ to recover the contents, as follows: 
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DKArncketA] = Tg, Tl. Kxa. X. G, A. U^.Ug.Ug.U^ 

[0057] The decrypted contents include the session key Kxa- "^^^ online service then uses the session key Kva to 
decrypt the time message and recover the time T, as follows: 

Dj^x^fTime Message] = T 



[0058] The online service 304 compares the recovered time sent from the game console with the current lime. If the 
recovered time is not within an allowable time horizon from the current time, the online service deems the game console 
15 102 as not authentic and the ticket as a forgery. In this case (i.e., the "No" branch from block 516), the online sen/ice 
denies service to the game console. 

[0059] On the other hand, if the recovered time is within an allowable time window from the current time, the online 
service is assured that the game console 102 is authentic. In this case (i.e.. the "Yes" branch from block 516), the 
online sen^ice generates a reply containing the time T in the request Time Message, encrypted with the session key 
Kxa. 2s follows: _ ^ 

f^^P'y = EkxaITI 

23 [0060] At block 518, the online service 304 returns the reply over the network 302 to the gaming system 1 00(1 ) (1. 
e., path 408). Once again, this reply is piggybacked on a regular online service reply and does not incur an extra 
communication trip. 

[0061] At block 520 in Fig. 5. the game console 102 evaluates the authenticity of the reply. The game console 102 
decrypts the reply using the session key Kxa that it previously received in the session key message from the key 

30 distribution center 306. If the game console 1 02 can successfully decrypt the reply, and the T value is the same as the 
T value originally sent in the Time Message, the game console is assured that the online service is authentic because 
the online service could not otherwise have known the random session key Kxa- In this case (i.e., the "Yes" branch 
from block 522), the game console is free to interact with the sen/ices offered by the online service (block 524). Oth- 
enrt^ise, If the reply cannot be decrypted successfully (i.e., the "No" branch from block 522), the game console deems 

35 the online service as not authentic and forgoes its services. 

[0062] The multi-user authentication process is built atop the three-participant model in the Kerberos authentication 
process. It differs from Kerberos In that it allows authentication of multiple users simultaneously, with one trip to the 
key distribution center and one ticket for all users. The extension involved, in part, defining new message strings to be 
passed among the participants. 

40 [0063] An alternative implementation is to leverage the existing well-defined data packets employed in the conven- 
tional Kerberos protocol. Kerberos defines a packet that includes a data field known as the "Pre-Auth" data field for 
pre-authorized data. In the alternate implementation, the multiple validated user identities (U^. H^), (Ug. Hg). (U3. H3). 
and (U4, H4) are inserted into this "Pre-Auth" data field so that all users are authenticated in the same request. Also 
the Kerberos tickets issued would be modified to contain extra "Authorization Data" that contains the user identities 

45 that have been authenticated {Ui,U2.U3.U4). 

Establishing Game Console Identity and Key 



[0064] The above multi-user authentication protocol hinges in part on the ability to establish the game console identity 
X and associated game console key Kx- This section describes how these parameters are created in the first place. 
[0065] Generally, each game console 1 02 is manufactured with secret information that is very difficult to guess and 
very difficult to access. Tamper resistant designs are employed to physically protect the secret infonnation on the game 
console from attacks on the hardware. The secret infonnation is stored at a backend server for use later at account 
creation time to verify whether the game console is authentic. The secret information may be the same for all or a batch 
55 of consoles, or unique for each console. Preferably, the secret information is unique so that if the information is com- 
promised, only a single fake account can be created. 

[0066] The establishment of a secure game console identity relies on the fact that console manufacturing is a reg- 
ulated process and that all consoles have consistent characteristics, regardless of the manufacturing date. It also relies 
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on the fact that because manufacturing is controlled by one or a linnited number of entities, a robust and secure database 
of the secret infomnation unique to each machine can be generated and used on the backend to verify that a particular 
game console is» in fact, a real console at the time a game console account is being created. 

[0067] Fig. 6 illustrates a process 600 for constructing a game console with secret information for use in establishing 
5 a console identity X and game console key Kx- The process 600 is performed in part during manufacturing and in part 
during account creation in which an online gaming account for the game console is created. These two phases are 
distinguished in Fig. 6 by a horizontal dashed line. The tasks are illustrated beneath headings "Manufacturing", "Au- 
thentication Server" and "Game Console" to convey exemplary locations as to where the tasks are performed^ 
[0068] At block 602, the manufacturer constructs the game console to Incorporate one or more pieces of information 
10 at the time of manufacture. The information is preferably of the type that can be made available programmatlcally. In 
one implementation, the game console is built to include at least two pieces of information, one that is unique to the 
individual machine and a second that is very difficult to guess and access. The first piece of infomiation need not be 
evenly distributed across a name space, nor does it need to be secret or hard to read, but it does need to be unique 
across the name space and accessible programmatlcally. For example, the first piece of information could be a console 
IS serial number assigned by the manufacturer, a hard disk ID printed on the hard disk drive, or a serial number-crf-any 
chip, ROM, firmware, or the like. This first piece of information will be used as the "name" of the game console to look 
up which row in table 650 corresponds to the particular game'console. 

[0069] The second piece of infomnation does not necessarily need to be unique per machine, but is evenly distributed 
across its namespace. It is very difficult to guess and very difficult to access. Programmatic access is pemnitted via 

20 secure techniques, such as code-signing techniques, but physical access is controlled via hardware-based solutions 
that resist tampering and render physical attack and reverse engineering very difficult. Examples of the second piece 
of Information include a CPU ID or a value derived from the CPU ID, such as a one-way hash of the CPU ID. Another 
example is a random key written onto disk at manufacturing time, the disk drive needs to be protected from unauthorized 
reading (like using the CPU ID) through some other means. This second piece of information will be used as the "key" 

25 for the game console, to prove that the game console is genuine and not some other computing device pretending to 
be a game console. 

[0070] At block 604, the infonnation is recorded in a database at the manufacturer as a set of database records 650. 
Each record includes, for example, an identity of the console, the hard disk ID (HDID), and the CPU ID. At block 606, 
the database records 650 are securely made available to an authentication server that may or may not be hosted by 
30 the key distribution center 306. In one implementation, a secure database replication procedure is employed to securely 
transfer the console Information database to the authentication server. It is further noted that the same entity may or 
may not control the manufacturing and authentication server. 

[0071] At this point, the two pieces of information can be used in the verification of the game console and creation 
of the game console identity X and key Kx- Such information can be used to verify, for example, that the game console 

35 is valid and not an impersonating personal computer. 

[0072] This completes the manufacturing phase of process 600. The game consoles are subsequently released from 
manufacturing and sold to consumers. When the user first decides to play an online game or access online services, 
the game console first obtains an account. This initiates the account creation phase of the process 600 in Fig. 6. 
[0073] At block 61 0, the game console submits the information, or data derived from the information, to the authen- 

40 tication server. The Infonnation could be sent over a secure link (e.g., SSL) established between the game console 
and the authentication server. In one implementation, the game console submits the hard disk ID and the CPU ID 
assuming a secure connection is established, such as using SSL to protect the contents of the message. To avoid 
exposing the CPU ID, another implementation is to submit in place of the CPU ID, a one-way hash digest of the CPU 
ID in such a way that it is extremely difficult to deduce the CPU ID from the resulting value. Another way to prove 

45 knowledge of the CPU ID and to also prevent replay attacks is to send Ecpuid(T) where the current time is encrypted 
with the CPU ID as the Key. 

[0074] At block 612, the authentication server evaluates the information from the game console. In one implemen- 
tation, the authentication server uses the information as an index into the console database records 650 to identify 
that the information is a correct combination of pieces. For instance, the authentication server determines whether the 
50 hard disk ID and CPU ID passed in from the game console form a correct pair recorded in the database as belonging 
to the same game console. If there is a match, the authentication server can be assured that the client is a valid game 
console because it would be very difficult for an impostor to guess, manually or programmatlcally, both pieces of in- 
formation and their relationship. 

[0075] At block 614, the authentication server looks up in the console database records to determine whether an 
55 account has already been established for this infonnation. If no account exists (i.e., the "No" branch from block 614), 
the authentication server creates an account and assigns a unique game console identity X and a randomly generated 
key Kx to that account (block 61 6). If an account exists (i.e., the "Yes" branch from block 61 4), the authentication server 
retrieves the existing account information (block 618). The game console identity X and key Kx are returned to the 
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game console (block 620). 

[0076] At block 622. the game console stores the game console identity X and key Kx In a secure way to resist 
hardware attacks. It also sends back a message containing the Identity X and the identity encrypted with the key Kv 
or ^KxW- Having the game console return a message allows the authentication serverto ascertain whether the game 
console correctly received the account data. If the decrypted Identity matches the non-encrypted identity the game 
console received the account data correctly. If the two do not match, the game console received incorrect data and 
the authentication server should delete the account and restart the process at block 61 0. If no reply is received from 
the game console, the authentication server cannot be sure if the account data successfully made it to the game 
console. In this case, the authentication server flags the account and waits for another new account creation for this 
game console (signifying that the game console did not receive the account data) or a successful logon (Indicating that 
the game console did receive the account data). 

[00771 At game time, the actual security of the console machine Is achieved via the identity X and key Kv. as described 
previously in the multi-user authentication process. 

'5 Conclusion 

[0078] The above processes are advantageous for many reasons. First, the multi-user authentication process is fast 
because it accomplishes all authentication for the gaming system, including multiple users, the game title, and the 
machine itself, in a single roundtrip communication with the key distribution center. After this initial roundtrip. the game 
console is able to communicate with any trusted services without re-communlcating with the key distribution center 
The whole process is accomplished with minimal user input and minimal delay before play can begin. The single ticket 
obtained from the authentication server is also unique in that it not only proves the particular game console, but also 
the multiple user identities playing aftFie game console. This is in contrast to the traditional approach where multiple 
tickets would need to be used (one for each authenticated principal). 

[0079] Although the invention has been described in language specific to structural features and/or methodological 
acts, it is to be understood that the Invention defined in the appended claims is not necessarily, limited to the specific 
features or acts described. Rather, the specific features and acts are disclosed as exemplary forms of implementinq 
the claimed Invention. 
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Claims 

1. A method comprising: 

initiating an online gaming activity from a gaming system with multiple users; and 

authenticating the multiple users together in a single request/reply exchange with an authentication entity. 

2. A method as recited in claim 1 . wherein the authenticating comprises: 

submitting a request from the gaming system to the authentication entity, the request containing identities of 
the multiple users; and 

returning a reply from the authentication entity to the gaming system that can be used to authenticate the 
multiple users in the online gaming activity. 

3. A method as recited in claim 1 , wherein the authenticating comprises: 

forming, at the gaming system, a request containing an identity string that includes a gaming system identity, 

multiple user identities, and an identity of an online service; 

submitting the request from the gaming system to the authentication entity; 

creating, at the authentication entity, a reply containing the identity string and a session key Kxa to be used 
in communication between the gaming system and the online service, the reply being encrypted with a key 
associated with the online service; and 

returning the reply from the authentication entity to the gaming system. 

4. A method as recited in claim 1 . wherein the authenticating comprises exchanging messages specified in the Ker- 
beros protocol, the response message containing a ticket having a authorization data field which acknowledges 
that multiple identities have been authenticated. 
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5. One or more computer-readable media comprising computer-executable instructions that, when executed, perform 
the method as recited in claim 1 . 

6. A method comprising: 

submitting a request from a game console to a ticket Issuing entity, the request containing a game console 
Identity, multiple user identities, and an identity of an online sen/ice; 

returning a ticket from the ticket issuing entity to the game console, the ticket containing the game console 
identity and the multiple user identities encrypted with a key associated with the online^ervice; 
passing the ticket from the game console to the online service; and decrypting the ticket at the online service, 
wherein after the decrypting the authenticity of the multiple users contained in the ticket Is trusted. 

7. A method as recited In claim 6. wherein the request further Includes an identity of the game console, and the game 
console identity is included in the issued ticket. 

8. A method as recited in claim 6, further comprising sending some cryptograph leal infomiation to prove knowledge 
of the user's key while submitting the request. 

9. A method as recited in claim 6, wherein the ticket further includes at least one of the online service identity, a time 
that the ticket is generated, a second time parameter Indicative of when the ticket expires, and a randomly gen- 
erated session key to be used in communication between the game console and the online service. 

10. A method as recited in claim 6, wherein the returning further comprises sending an attached message along with 
the ticket from the ticket issuing entity to the game console, the message containing a randomly generated session 
key to be used in communication between the game console and the online service. 

11. A method as recited in claim 10. wherein the attached session message Is encrypted with a key associated with 
the game console. 

12. A method as recited in claim 10, wherein the passing comprises sending a second message with a current time 
encrypted with the session key. 

13. A method as recited In claim 12. wherein the ticket further includes a randomly generated session key and the 
verifying, at the online service, further comprises: 

decrypting the ticket using the key associated with the online service to recover the session key; 
decrypting the second message with the session key to recover the current time; and 
authenticating the multiple users and the game console in the event that the recovered current time is within 
an acceptable time window from the current time. 

14. A method as recited in claim 6, further comprising: 

sending a reply from the online service to the game console; and 
verifying, at the game console, an authenticity of the reply. 

15. One or more computer-readable media comprising computer-executable instructions that, when executed, perform 
the method as recited In claim 6. 

16. A method comprising: 

creating, at a game console, multiple validated user identities (U^. H^), (U2. Hg). .... (Uu. Hy) composed of 

user identities U^, Ug and associated values H,, Hg, .... derived from the user's key; 

forming, at the game console, a request containing an identity string that includes a game console Identity X, 
a game title Identity G, the multiple validated user identities, and an identity A of an online service, as follows: 



Request = [X, G, A, (U^ , H^) (U^. H^)]; 
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submitting the request from the game console to a ticket issuing entity; 

creating, at the ticlcet issuing entity, a ticl^et containing the identity string and a session l<ey Kxa encrypted with 
a key K^^ associated with the online service, as follows: 

Ticket = Eka[Kxa. X. G, A, .Ua.Ug.U J; 

sending the ticket along with the session key Kxa ^^^'^ ticket issuing entity to the game console; 
passing the ticket from the game console to the online service along with data encrypted using the session 
10 key Kxa; 

verifying the ticket at the online service by decrypting the ticket using the online service key Ka. extracting the 
session key Kxa ^^^^ decrypted ticket, and decrypting the data from the game console using the session 
key Kxa- 

IS 17. A method as recited in claim 16, wherein the creating comprises computing cryptographic hash digests of user 
keys associated with the multiple users, each user Identity being a combination of the user identity and the cryp- 
tographic hash of an associated user key. 

18. A method as recited In claim 16, wherein the creating comprises encrypting a time value using keys associated 
with the multiple users, each user identity being a combination of the user identity and the current time encrypted 
with the user key. 

19. A method.as recited in claim 1 6, wherein the request further includes an identity of the game console. 

25 20. A method as recited In claim 1 6. wherein the ticket further Includes at least one of a time that the ticket is generated 
and a second time parameter indicative of when the ticket expires. 

21 . A method as recited in claim 1 6, further comprising encrypting the session key Kxa with a key associated with the 
game console before said sending of the session key to the game console. 
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22. A method as recited In claim 1 6. wherein the data comprises a time value representative of a current time. 



23. A method as recited in claim 16, wherein the data comprises a time value representative of a current time, and 
the verifying comprises authenticating the game console and the multiple users in an event that the time value 

•35 received from the game console is within an acceptable time window from a current time. 

24. A method as recited in claim 23. further comprising: 

sending a reply from the online sen/ice to the game console, the reply containing the time value encrypted 
<o using the session key Kxa! and 

verifying, at the game console, an authenticity of the online service in an event that the game console suc- 
cessfully decrypts the time value using the session key Kxa. and the time value returned matches the time 
value sent to the online service. 



45 



25. One or more computer-readable media comprising computer-executable instructions that, when executed, perform 
the method as recited In claim 1 6. 



26. A method for operating a game console, comprising: 

submitting a request to a ticket issuing entity, the request containing multiple user identities and an identity of 
an online service; and 

receiving a single ticket from the ticket issuing entity that can be used to authenticate the multiple user identities 
to the online service. 

27. A method as recited in claim 26, wherein the request further includes at least one of an identity of the game console 
and an identity of a game title being played In the game console. 

28. A method as recited in claim 26, further comprising cryptographlcally deriving the user identities from information 
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associated with the users. 

29. A method as recited in claim 26, wherein the ticket includes at least one of (1) the multiple user identities, (2) the 
identity of the online service, (3) an Identity of the game console, (4) an identity of a game title being played In the 

5 game console, (5) a time that the ticket is generated, (6) a second time parameter indicative of when the ticket 

expires, and (7) a randomly generated session key to be used in communication between the game console and 
the online service. _ 

30. A method as recited in claim 26, further comprising sending the ticket to the online service. 

10 

31. One or more computer-readable media comprising computer-executable instructions that, when executed, perform 
the method as recited In claim 26. 

32. A method for operating a game console, comprislag: 

IS ^ 

submitting a request to a ticket issuing entity, the request containing multiple user Identities and an identity of 
the game console; and 

receiving a single ticket from the ticket issuing entity that can be used to authenticate the multiple user identities 
and the game console. 

20 

33. A method for operating a game console; comprising: 

creating a request with multiple user identities of multiple users who are playing on a game console; and 
submitting the request to a third party. 

25 

34. A method as recited in claim 33, wherein the request includes at least one of an identity of an online service, an 
identity of the game console, an Identity of a game title being played in the game console. 

35. A method as recited in claim 33, further comprising receiving a single ticket from the ticket issuing entity that can 
30 used to authenticate the multiple user identities to another entity. 

36. One or more computer-readable media comprising computer-executable instructions that, when executed, perform 
the method as recited in claim 33. 

35 37. A method comprising: 

receiving a request from a game console, the request containing multiple user identities of multiple users who 
are playing at the game console and an identity of a third party; 

generating a single ticket to be used to authenticate the multiple user identities to the third party; and 
40 returning the ticket to the game console. 

38. A method as recited in claim 37, wherein the request further includes at least one of (1) an identity of the game 
console and (2) an identity of a game title being played in the game console. 

45 39. A method as recited in claim 37, wherein the ticket includes at least one of (1) the multiple user identities, (2) the 
identity of the third party, (3) an identity of the game console, (4) an identity of a game title being played in the 
game console, (5) a time that the ticket is generated, (6) a second time parameter indicative of when the ticket 
expires, and (7) a randomly generated session key to be used in communication between the game console and 
the third party. 

50 

40. A method as recited in claim 37, further comprising encrypting the ticket with a key associated with the third party 
prior to said returning the ticket. 

41. A method as recited in claim 37, further comprising: 

55 

generating a session key to be used in communication between the game console and the third party; and 
sending the session key to the game console. 
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42. One or more computer-readable media comprising computer-executable instructions that, when executed, perform 
the method as recited In claim 37. 

43. A method comprising: 

s 

receiving a request from a game console, the request containing multiple user identities of multiple users who 
are playing at the game console; and 

issuing a single ticket to be used to authenticate the multiple user identities. 
10 44. A method comprising: 

receiving a request from a game console, the request containing multiple user identities of multiple users who 
are playing at the game console and an identity of the game console; and 

issuing a single ticket to be used to authenticate the multiple user identities and the game console, _ 

15 

45. A method for manufacturing a game console, comprising: 

constructing a game console with associated authentication information; and 

storing the authentication information in a database to be used for authenticating the game console after the 
20 game console is released from manufacturing. 

46. A method as recite3Th claim 45, wherein the authentication information comprises at least one of a hard disk drive 
ID. a CPU ID, a first value derived from the hard disk ID. a second value derived from the CPU ID. and a third 
value derived from a combination of the hard disk drive ID and the CPU ID. 

23 

47. A method as recited in claim 45, wherein the authentication Infomnation comprises one or more serial numbers of 
hardware components in the game console. 

48. A method as recited in claim 45, wherein the authentication information comprises a random key generated at 
30 manufacturing time. 

49. A method as recited In claim 45, further comprising securely transferring the database to an authentication site for 
access by an authentication server. 

35 50. A method as recited In claim 45, further comprising crSeating. at the authentication server, account names/pass- 
words for the game consoles identified in the database. 

51 . One or more computer-readable media comprising computer-executable Instructions that, when executed, perform 
the method as recited in claim 45. 

40 

52. A method for validating an authenticity of a game console, comprising: 

receiving, from the game console, authentication infomiation that is associated with the game console at a 
time of manufacturing; and 
^5 evaluating the authentication information to delemnlne whether the game console is valid. 

53. A method as recited in claim 52, wherein the authentication information comprises at least one of a hard disk drive 
ID, a CPU ID, a first value derived from the hard disk ID, a second value derived from the CPU ID. and a third 
value derived from a combination of the hard disk drive ID and the CPU ID, 

so 

54. A method as recited in claim 52, wherein the evaluating comprises using a database of authentication information 
for game consoles to detemnine whether the authentication is valid. 

55. A method as recited in claim 52, wherein the evaluating comprises ascertaining whether an account for the game 
console associated with the authentication information has already been established. 

56. A method as recited in claim 52. further comprising. In an event that the game console is valid, generating an 
Identity and a cryptographic key for the game console. 
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57. A method as recited in claim 52, further comprising, in an event that the game console is valid, creating an account 
for the game console. 

58. One or more computer-readable media comprising computer-executable instructions that, when executed, perform 
the method as recited in claim 52. 

59. A computer-readable medium for a game console comprising computer-executable instructions that, when exe- 
cuted, direct the ganne console to:, ^ « 

create multiple validated user identities (U^, H^), (Ug. Hg) (Uy. Hy) composed of the multiple user identities 

U.,, U2, .... Uu and associated values H-,. Hy derived from the user's key; 

form a request containing a game console identity X, a game title identity G. the multiple user identities, and 
an identity A of an online service, as follows: 

Request =[X, G. A, (U^, H^). .... (U^, Hu)]; 

and 

submit the request to a ticket issuing entity over a network. 

60. A computer-readable medium as recited in claim 59, further comprising computer-executable instructions that, 
when executed, direct the game console to compute cryptographic hash digests of user keys associated with the 
multiple users, each user identity being a combination of the user identity and the cryptographic hash of an asso- 
ciated user key. 

61. A computer-readable medium as recited in claim 59, further comprising computer-executable instructions that, 
when executed, direct the game console to encrypt a time value using keys associated with the multiple users, 
each user identity being a combination of the user identity and the encrypted time value. 

62. A computer-readable medium as recited in claim 59, further comprising computer-executable instructions that, 
when executed, direct the game console to form the request to further include at least one of an identity of the 
game console, a random nonce, and a checksum value to ensure receipt of all contents of the request. 

63. A computer-readable medium as recited in claim 59, further comprising computer-executable instructions that, 
when executed, direct the game console to: 

receive a ticket from the ticket issuing entity, the ticket containing the game console identity X, the game title 
identity G, the multiple user identities, the online service Identity A, and a session key K^a together encrypted 
with a key associated with the online service, as follows: 

TicketA =Eka[Kxa. Xi A. Ui.U2....Uul; 

receive the session key Kxa ^rom the ticket issuing entity; and 

pass the ticket from the game corisole to the online service along with some information encrypted using the 
session key K^a- 

64. A corriputer-readable medium comprising computer-executable instructions that, when executed, perform opera- 
tions comprising: 

receive a request from a game console, the ticket containing an identity string that includes a game console 
identity X, a game title identity G, multiple user identities (U^, H^). .... (11^. Hy), and an identity A of an online 
service, as follows: 

Request = [X, G. A, (U^ , H^) (U^, Hy)]; 



and 
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generate a ticket containing the identity string and a session key Kxa together encrypted with a key asso- 
ciated with the online service, as follows: 
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TicketA = EkaLKxa. X, G, A, U^.U2,...Uul; 

and 

return the ticket to the game console. 

65. A computer-readable medium as recited in claim 64, further comprising connputer-executable instructions that, 
when executed, direct the game console to generate the request to further include at least one of a time that the 
ticket Is generated and a time length before expiration of the ticket. 

66, A computer-readable medium as recited in claim 64, further comprising computer-executable instructions that, 
when executed, direct the game console to encrypt the session key Kxa with a key associated with the game 
console and send the encrypted session key to the game console. 



67. A single gaming ticket data structure embodied on a computer readable, comprising multiple user identities of 
users playing at a game console, encrypted using a key associated with a third party entity to which the multiple 

20 users are to be authenticated. 

68. A single gaming ticket data structure embodied on a computer readable, comprising multiple user identities of 
users playing at a game console and an identity of the game console, encrypted using a key associated with a 
third party entity to which the multiple users are to be authenticated. 



69. A gariie console, comprising: 



a memory; and 

a processor coupled to the memory, the processor being configured to obtain authentication of multiple users 
30 of the game console together in a single request/reply exchange with an authentication entity. 

70. A game console as recited in claim 69, wherein the request contains a game console identity, a game title identity 
of a game being played in the game console, multiple user identities, and an Identity of an online service. 

35 71. A game console as recited in claim 70, wherein the memory comprises a hard disk drive with an associated hard 
disk ID and the processor has an associated processor ID, and the processor is configured to submit at least one 
of the hard disk ID, the CPU ID. and a value derived from the CPU ID to a third party as part of a process to obtain 
the game console identity. 

40 72. A system, comprising: 



a ticketing issuing entity; 

a game console configured to submit a request to the ticket issuing entity, the request containing multiple user 
identities and an identity of an online sen/ice; and 

the ticket issuing entity being configured to generate a single ticket that can be used by the game console to 
authenticate the multiple user identities to the online service. 



73. A system, comprising: 



so a ticketing issuing entity; 

a game console configured to submit a request to the ticket issuing entity, the request containing multiple user 
identities; and 

the ticket issuing entity being configured to generate a single ticket that can be used by the game console to 
authenticate the multiple user identities to a third party. 

55 

74. A system, comprising: 

a ticketing issuing entity; 
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a game console configured to subnnit a request to the ticket issuing entity, tlie request containing multiple user 
identities and an identity of the game console; and 

the ticket Issuing entity being configured to generate a single ticket that can be used by the game console to 
authenticate the multiple user identities and the game console to a third party. 
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